Hardware virtualization technologies enable a computer system (typically called a “host” machine or computer system) to create one or more “virtual” machines or computer systems (typically called “guests”). Thus, virtualization technologies enable a computer system running a “host” operating system to execute in isolation one or more “guest” operating systems of the same type or even of a different type. Hardware virtualization technologies come in two major forms: full virtualization and paravirtualization. Full virtualization is an almost complete simulation of actual hardware. Full virtualization allows guest operating systems and software to run unmodified on the host system, sometimes even if they are binary encoded using a different Instruction Set Architecture (ISA) from the host. Paravirtualization, on the other hand, does not simulate a full hardware environment. Instead, guest operating systems and software are executed in their own isolated domains. However, guest operating systems need to be specifically modified to run in paravirtualized environments, and typically need to be binary encoded to the same ISA as the host. The software that creates a virtual machine on the host hardware is often referred to as a hypervisor or Virtual Machine Manager (VMM).
Hardware virtualization technologies have seen a great deal of adoption in recent years, particularly with the proliferation of hosted computing environments (e.g., “cloud” computing). While virtualization can be carried out entirely in software, particularly in the context of paravirtualization the speed and efficiency of virtualization can be greatly improved with the help of microprocessor (referred to herein simply as processors or CPUs) features.
For example, like any other computer, virtual machines need access to system memory, such as Random-Access Memory (RAM). In order to facilitate providing virtual machines efficient access to system memory, many processor vendors have implemented features known generically as second level address translation (SLAT). For example, INTEL, INC's present implementation is known as Extended Page Table (EPT), while ADVANCED MICRO DEVICE, INC's (AMD's) present implementation is known as Rapid Virtualization Indexing (RVI). In general, SLAT implementations maintain an on-processor hardware cache—which is accessible by a hypervisor/VMM—that stores mappings between guest-physical memory addresses (GPAs) and host-physical memory addresses (HPAs). A guest-physical address is a “virtual” address that is presented by the host to a virtual machine as if it were an actual location (e.g., a memory page) in physical memory. A host-physical address, on the other hand, is an actual address to a location (e.g., a memory page) in real physical memory. When a SLAT structure is filled with valid GPA-to-HPA mappings for a virtual machine, this structure can be used by the hypervisor/VMM to obtain appropriate host-physical addresses for the virtual machine directly, without having to go through a context switch to a host memory manager (e.g., such as when the virtual machine tries to access the corresponding guest-physical address).
One way to provide a virtual machine with access to system memory is for the host's memory manager to allocate system memory to the virtual machine directly. In these circumstances, the SLAT structure is filled with GPA-to-HPA mappings upon instantiation, and these mappings typically remain valid the entire time the virtual machine is running. These “physical” virtual machines therefore have essentially full control over their allocated physical memory, making that physical memory unavailable to the host's memory manager for other purposes (e.g., allocation to other processes) while the virtual machine is running.
Another way to provide a virtual machine with access to system memory is for the host's memory manager to allocate virtual memory addresses, rather than host-physical addresses, to the virtual machine when it is instantiated—much as the memory manager might do when instantiating normal processes. In these circumstances, one or more host page tables are filled with the virtual memory addresses that are allocated to the virtual machine, but physical memory may not actually be allocated to each of these virtual addresses. Thus, the SLAT structure may not be filled with GPA-to-HPA mappings upon the virtual machine's instantiation; instead, these mappings are filled on-demand as the virtual machine accesses its guest-physical addresses. Use of “virtual address-backed” (VA-backed) virtual machines gives the host's memory manager essentially the same flexibility to allocate physical memory to—and deallocate physical memory from—virtual machines as it does for any other process.
A common practice when using virtual memory systems is to “trim” memory pages from running processes. In particular, a host's memory manager might occasionally “walk” a working set of valid page table entries (PTEs) for a process while updating “aging” information for the physical memory pages referenced in those PTEs. Part of this process includes clearing an accessed flag within each of those PTEs, if it is set, so that the memory manager can determine if a corresponding memory page has been accessed since the last time the working set was walked for aging information. In general, aging information tracks a notion of how long it's been since the page was last accessed, such as how “hot” or “cold” the page is (i.e., the more recently accessed the page is the “hotter” it is, and the least recently accessed the page is the “colder” it is). When there is pressure for physical memory, a memory manager might “trim” older/colder pages from a process so that it can reassign the trimmed pages to another process, while committing each trimmed page's data to secondary storage where it can be retrieved the next time the process tries to access it.
The performance of hosts and guest VMs, when using VA backed virtual machines, may be improved, as will be made clear in view of the disclosure herein.